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Discussion 

The Examiner has concluded that the figures in the Applicant's application (the 
"Applicants' figures", referred to by the Examiner as "HFE") are properly considered as 
prior art. The Examiner bases his conclusion on determinations that 1) the present 
application is not entitled to claim the priority date of the provisional application to which 
it claims priority and thus the Applicants' figures raise a statutory bar under 35 U.S.C. 
102(b), and/or 2) the Applicants have admitted that their figures are the prior art of 
another under MPEP 2129. 

The Examiner has failed to identify any evidence to support his determinations 
and, in fact, the Examiner's determinations are contrary to the available evidence. 
Accordingly, the Applicants' figures, which form the basis for all of the Examiner's 
rejections of the claims in appeal, are not available as prior art under U.S.C. 102(b) nor 
are they admitted prior art under MPEP 2129. 

Discussion re: 35 U.S.C. 102(b) 

1. The Priority Date of the Present Application is August 3 K 1999 

The Examiner has defended his reliance upon the Applicants' figures to reject the 
present claims based upon determinations made for the first time in his Answer. Based 
upon these determinations, the Examiner concludes that the Applicants cannot claim 
priority to their provisionally filed application. There is no basis for the Examiner's 
rejection of the claim for priority. 
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Specifically, the Examiner has now alleged that "the appellant's claim for priority 
(60/151,269) is improper due to information inconsistencies between the priority 
document and the application (09/653, 196)." 1 (Examiner's Answer at p. 16). The 
Examiner has failed, however, to provide any legal basis for denying a claim to priority 
merely because of differences in information between a provisional application and a 
non-provisional application. 

Contrary to the Examiner's position, there is no requirement for identity of 
information between a provisional application and a non-provisional application. In fact, 
35 U.S.C. 1 12 has been interpreted to require that "the best mode contemplated by the 
inventor at the time of filing the application" must be disclosed. (MPEP at 608.01(h)). 
Accordingly, a non-provisional application is required to include information not 
provided in the provisional application to which it claims priority if there are changes in 
the contemplated best mode. Therefore, there is no basis for the Examiner's position. 

The requirements for claiming priority in the present instance are established by 
35 U.S.C. 1 19(e) with further requirements established in MPEP 201.1 1. As set forth 
therein, the Applicants are entitled to their claim of priority to a properly filed provisional 
application if (1) the later filed non-provisional application includes an invention 
disclosed in the provisional application, (2) the non-provisional application includes an 
inventor listed in the provisional application, (3) the non-provisional application is filed 
not later than 12 months after the date on which the provisional application was filed, (4) 
the non-provisional application contains or is amended to contain a specific reference to 
the provisional application, (5) the claim for benefit is made within four months of the 

1 The Examiner has incorrectly identified the application to which priority is claimed. The present 
application claims priority to U.S. Application No. 60/151,629, filed August 31, 1999. 
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filing of the non-provisional application, and (6) the disclosure of the invention in the 
provisional application was not defective. 

a. An Invention Disclosed in the Provisional Application is Claimed 
The present application (the " 6 196 application") claims an invention disclosed in 
the Provisional Application No. 60/151,629 (the " '629 application/' (a copy of which is 
attached hereto as Exhibit A for the Board's convenience)). By way of example, each of 
the elements of claim 1 of the '196 application are set forth below followed in parenthesis 
by a specific page and line number and/or figure number of the '629 application wherein 
the element is disclosed. 
Claim 1 recites: 

A method of quantitatively evaluating alternatives to check-out operations using 
simulation model, comprising: 

selecting from a data input dictionary parameters describing a first check-out 
operations; [page 18, line 1 through page 21 line 23 and FIG. 8) 

inputting parameter values for the selected parameters describing the first check- 
out operations into the simulation model; [page 22 line 1 through page 26 line 16 and 
FIGs. 9-12] 

transforming the first check-out operation parameters into check-out performance 
results; and [page 31, lines 4-22 and FIGs. 25-27] 

outputting the results from the simulation model [page 31 line 25 through page 33 
line 5 and FIGs. 28-29]. 

Therefore, because every element of claim 1 of the '196 application is disclosed 
in the '629 application, the '196 application claims an invention disclosed in the '629 
application and the first requirement is met. 
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b. The '196 Application and '629 Application Have the Same Inventors 

With respect to the inventors for the '196 application and the '629 application, a 
comparison of the corrected filing receipt for the '196 application with the filing receipt 
for the '629 application demonstrates that there is a unity of inventors. (See filing 
receipts for ' 196 application and the '629 application, copies of which are attached hereto 
as Exhibits B and C, respectively). Therefore, the requirement for a common inventor is 
met. 2 

c. The ' 196 Application Was Timely Filed 

The '629 application was filed on August 31, 1999. (See Exhibit C). The 196 
application was filed on August 31, 2000. (See Exhibit B). August 31, 2000, is not later 
than 12 months after the August 31, 1999. Therefore, the '196 application was filed 
within the required timeframe. 

d. The ' 196 Application Includes a Specific Claim of Priority 

The '196 application was originally filed with a claim of priority. (See 
Specification at page 1, lines 3-6). Although the initial specification included a 
typographical error transposing a "2" and a "6", the error was corrected as reflected by 
the filing receipt shown in Exhibit B. The error was also corrected in the specification. 
(See Applicants 5 Amendment dated March 30, 2004). Therefore, the 6 196 application 
includes a specific reference to the '629 application. 

2 The filing receipts show a discrepancy as to whether "Doug" or "Douglas" is Mr. Poynter's first name or 
middle name; however, only one common inventor is required and Mr. Cash clearly satisfies that 
requirement. 
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e. The Claim to Priority Was Timely Made 

As set forth above, the '196 application was originally filed with the claim of 
priority. Accordingly, the claim of priority was made within four months of the filing of 
the '196 application as required by MPEP 201.1 1. 

d. The Disclosure in the 6 629 Application is Sufficient 

The '629 application includes twenty sheets of drawings with twenty-one figures. 
The specification includes a discussion of the background of the invention, a summary of 
the invention and over thirty pages of detailed description of the invention. To a large 
extent, the disclosure of the '196 application mirrors the disclosure of the '629 
application. The main difference is that the particular model selected from the input 
module for use in providing a detailed description of the disclosed embodiment is 
different. (See e.g. FIG. 5 et seq. of the '629 application compared to FIG. 7 et seq. of 
the 196 application). 

Accordingly, because the two applications are so similar, and because the 
Examiner has never alleged that the '196 application does not adequately support its 
claims, it is reasonable to conclude that the disclosure in the '629 application is sufficient. 

e. Conclusion 

The Examiner has identified no authority for the denial of a claim to priority 
merely for differences in the information between applications. Moreover, as set forth 
above, all of the requirements for claiming priority to the '629 application have been met 
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for the 6 196 application. Therefore, the 4 196 application is entitled to the priority date of 
the '629 application. Thus, the priority date for the '196 application is August 31, 1999. 

2. The Alleged Date of Publication of the Figures Does Not Raise a Statutory Bar 
The Examiner has alleged that the publication date to be ascribed to the 

Applicants' figures is February 24, 1999. (Examiner's Answer at p. 16). As set forth 
above, the priority date for the present application is August 31, 1999. Therefore, 
because the alleged publication date is less than a year before the priority date of the 
present application, the Applicants' figures do not raise a statutory bar under 35 U.S.C. 
102(b). 

3. The Evidence Does Not Support the Examiner's Rejection 

In rejecting an application, factual determinations by the USPTO must be based 
on a preponderance of the evidence, and legal conclusions must be correct." In Re 
Glaug, 283 F.3d 1335 (Fed. Cir. 2002)(citing In re Oetiker, 977 F.2d 1443, 1445, 24 
USPQ2d 1443, 1444 (Fed. Cir. 1992). Thus, assuming arguendo that the Applicants' are 
not entitled to their claim of priority, to be available as a publication under 35 U.S.C. 
102(b), the preponderance of the evidence must show that the Applicants' figures were 
not only published, but also that they were published more than a year before the filing 
date of the '196 application. The preponderance of the evidence does not support the 
Examiner's determination that the Applicants' figures were published, or that they were 
published more than a year before the filing date of the 6 196 application. 
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a. There is No Evidence That the Applicants' Figures Were Ever Published 

As an initial matter, the Federal Circuit has stated that "[a] document, to serve as 
a "printed publication", must be generally available." Northern Telecom, Inc. v. 
Datapoint Corp., 908 F.2d 931, 936 (Fed. Cir. 1990). There is no evidence of any public 
disclosure of the Applicants' figures. 

The only evidence of any disclosure of either the figures in the '629 application or 
the figures in the 4 196 application is that the figures in the 4 629 application were 
submitted to the USPTO as part of the '629 application on August 31, 1999 and that the 
figures in the '196 application were submitted to the USPTO as part of the '196 
application on August 31, 2000. Under 37 CFR 1.14, however, applications are 
maintained confidential by the USPTO until some qualifying event. The Applicants' are 
not aware of any evidence of action by the USPTO to publish or disclose the contents of 
the '629 application or the '196 application. 

Therefore, there is no evidence that the Applicants' figures are publications under 
35 U.S.C. 102(b). 

b. Any Publication by Filing Was Within One Year of the Filing 
Moreover, 35 U.S.C. 102(b) requires the date of publication to have occurred 

more than one year prior to the filing date of the application. Therefore, even if the 
disclosure of the figures in the '629 application to the USPTO as part of the '629 
application is considered to be a publication, the date of publication would be August 31, 
1999. Therefore, because the '196 application was filed on August 3 1 , 2000, the filing 
date of the '629 application does not meet the one year limitation of 35 U.S.C. 102(b). 
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c. There is No Evidence to Support the Alleged Publication Date 
Furthermore, the date selected by the Examiner for the alleged publication of the 
Applicants' figures has no evidentiary support. As stated in the Appeal Brief, the 
publication date ascribed to the Applicants' figures by the Examiner is apparently based 
upon FIG. 14 of the 6 196 application, which includes a February 1999 date. There is, 
however, no indication on FIG. 14 as to the purpose of showing a February 1999 date. 
Significantly, FIG. 14 depicts a first page of a data input dictionary. Thus, the most 
reasonable meaning attributable to the February 1999 date is that the data input dictionary 
was last modified on that date. 

Moreover, assuming arguendo that the Applicant's figures are reproductions of a 
publication, the first slide would be FIG. 4 of the 6 196 application, since FIG. 4 depicts a 
main menu for the model. (See FIG. 4). FIG. 14 of the 4 196 application is thus almost 
halfway through the alleged presentation. The date on which a presentation is given, 
however, is generally found on the first slide of the presentation, not buried midway 
through the presentation. This fact weighs against the February 1999 date being a 
publication date. 

Of course, FIG. 4 of the '196 application does include a year, 1999. Nonetheless, 
even assuming arguendo, in addition to the assumption that the Applicants' figures were 
a publication, that FIG. 4 identified the date of the publication, there is no basis for 
determining that the publication was February 1999 as opposed to December 1999. 
Accordingly, because FIG. 4 does not identify what month of 1999 the alleged 
publication occurred, there is no evidence that the publication occurred before or after 
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August 31,1 999. Therefore, there is no evidence to support the determination that the 
Applicants' figures were published more than one year before the filing of the 6 196 
application on August 31 2000. 

Consequently, to the extent that there is any evidence in support of a particular 
date of publication, that evidence is competent only for indicating the year 1999. There 
is no evidence, however, that supports any particular month of 1999. Therefore, the 
preponderance of the evidence does not support a determination that the Applicants' 
figures were published more than one year prior to the filing of the '196 application. 

d. Conclusion 

Therefore, for any or all of the above reasons, even assuming arguendo that the 
Applicants' are not entitled to their claim of priority, the preponderance of the evidence 
does not support the Examiner's determination that the Applicants' figures were 
published or were published more than a year before the filing date of the * 196 
application so as to raise a statutory bar under 35 U.S.C. 102(b). 3 

Discussion re: MPEP 2129 

The Examiner has also concluded that reliance on the Applicants' figures to reject 
the claims in the present application is supported by MPEP 2129. In support of this 
conclusion, the Examiner has stated that the Applicants' figures "appear to be analogous 
to a Power Point presentation - thus appearing as a stand alone document — with no one 



Of course, given the dearth of evidence supporting the Examiner's positions newly presented in his 
Answer, it is puzzling that a request for information under 37 CFR 1 . 105 as discussed in the MPEP at 
704.10 was not made so as to enable a proper determination of the facts. 
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(sic) disclosure of credit to either assignee or appellant." (Examiner's Answer at page 
16). The Examiner's reliance upon MPEP 2129 is unfounded. 

1 . The Applicant Has Never Identified the Figures as Prior Art 

The phrasing used by the Examiner suggests that the Examiner is relying upon the 
statement in MPEP 2129 that "the examiner must determine whether the subject matter 
identified as "prior art" is applicant's own work, or the work of another. In the absence of 
another credible explanation, examiners should treat such subject matter as the work of 
another." The Examiner has ignored, however, that the "prior art" must be identified as 
such by the applicant, not by the Examiner. 

Specifically, MPEP 2129 states that "[a] statement by an applicant during 
prosecution identifying the work of another as "prior art" is an admission that that work is 
available as prior art against the claims, regardless of whether the admitted prior art 
would otherwise qualify as prior art under the statutory categories of 35 U.S.C. 102." 
(MPEP 2129 citing to Riverwood Int'l Corp. v. R.A. Jones & Co., 324 F.3d 1346, 1354, 
66 USPQ2d 1331, 1337 (Fed Cir. 2003)(emphasis in original)). Thus, it is only once an 
applicant admits that something is prior art that any presumption of non-attribution is 
allowed. The applicant has never identified the Applicants' figures as prior art. 

As an initial matter, the figures do not bear any marking that they are prior art. 
Additionally, the '629 application includes a background section that is included in the 
background section of the '196 application. Neither background section identifies the 
accompanying figures as prior art. Moreover, the brief description of the drawings in 
both inventions identifies the accompanying figures as illustrating the "present 
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invention". Finally, a review of the Applicants' amendments and Appeal Brief did not 
identify any admission by the Applicant that the Applicant's figures were prior art. 

Therefore, there is no basis for a determination that the Applicants have identified 
the Applicants' figures as prior art in the 6 196 application, the '629 application, or at any 
time during prosecution of the 6 196 application. 

2. The Replacement Drawings Were Properly Identified 

The intent of the Examiner in analogizing Applicants' figures to a power point 
presentation is not clear. To the extent that the Examiner intended to state that the 
replacement drawings were submitted without any indication as to what they were, the 
Examiner is mistaken. 

In the Amendment dated March 30, 2004, the amendment clearly states that 
replacement drawings were included. Moreover, the transmittal letter identified the 
contents of the package as replacement drawings. Therefore, there can be no confusion 
as to whether or not the replacement drawings were intended to be replacement drawings 
or an unidentified and unacknowledged submission of prior art. 4 The replacement 
drawings were clearly identified as replacement drawings. 

3. The Appearance of Figures Does Not Constitute an Admission 

Of course, the Examiner does emphasize the appearance of the Applicant' figures, 
as he noted that they "appear to be analogous to a Power Point presentation - thus 
appearing as a stand alone document". (Answer at page 16 (emphasis added)). Thus, the 

4 The post card identifying the contents of the package including the replacement drawings and mailed by 
the PTO does not identify any figures or presentations in addition to the identified replacement drawings. 
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Examiner may have been attempting to state that the look of the Applicants' figures raises 
a presumption that the Applicants admit that their figures are prior art under MPEP 2129. 
The Examiner has failed to identify any legal basis for such a conclusion. 

As an initial matter, there is nothing in MPEP 2129 that discusses how the look of 
a figure provides a basis for determining that an applicant is making a prior art admission. 
Rather, MPEP 2129 appears to be rather clear in restricting the scope of admissions to 
actual statements. 

Moreover, the Examiner's rationale requires a presumption that if the figures 
submitted in support of the disclosure of an invention resemble figures that can be 
produced using commercially available presentation software, then there is a presumption 
that the figures are in fact reproductions of presentation slides. Of course, virtually any 
image may be readily reproduced using commercially available presentation software. 
Accordingly, under the Examiner's rationale, all figures submitted to the USPTO as part 
of a patent application are presumably reproductions of presentation slides. The 
Applicants are not aware of any legal basis for such a presumption and the Examiner has 
failed to identify any such legal basis. 

Moreover, there must also be a presumption that all figures filed with an 
application were actually presented to an audience in a manner sufficient to constitute a 
"publication". Again, the Applicants are not aware of any legal basis for such a 
presumption and the Examiner has failed to identify any such legal basis. 

In fact, the MPEP suggests that there is no presumption that figures submitted 
with an application are reproductions of prior art publications. For example, the MPEP 
608.02(g) states that "[fjigures showing the prior art are usually unnecessary and should 
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be canceled. Ex parte Elliott, 1904 CD. 103, 109 O.G. 1337 (Comm'r Pat. 1904). 
However, where needed to understand applicant's invention, they may be retained if 
designated by a legend such as "Prior Art. 11 " Obviously, there would be no need to label 
figures as prior art if all figures were presumed to be prior art. 

Therefore, there is no basis for concluding that figures submitted with a patent 
application are admitted to be prior art by the applicant based solely upon the appearance 
of the figures. 

4. Conclusion 

Therefore, for any or all of the above reasons, the preponderance of the evidence 
does not support the Examiner's new conclusion that the Applicants' figures are admitted 
prior art under MPEP 2129. 5 



5 Interestingly, during the time the '196 application was being examined, the Examiner never suggested that 
the Applicants' figures needed to be corrected by either canceling the Applicants' figures or by amending 
them to state that they were prior art as required by the MPEP 608.02(g). Thus, the Examiner's own 
actions contradict his newly formed determination that the Applicants' figures are admitted prior art under 
MPEP 2129. 
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Conclusion 

For the reasons set forth above, the Applicants' figures are not properly 
considered as prior art. Therefore, for all of the reasons set forth in the Applicants' 
Appeal Brief, claims 1, 3-18 and 20-31 are not unpatentable under 35 U.S.C. § 103(a). 
As a consequence, the Board of Appeals is respectfully requested to reverse the rejection 
of these claims. 



April 8, 2005 

Maginot Moore & Beck LLP 
Bank One Tower/Center 
1 1 1 Monument Circle, Suite 3000 
Indianapolis, Indiana 46204-5115 
Telephone: (317)638-2922 
Facsimile: (317)638-2139 



Respectfully submitted, 
MAGINOT, MOORE & BECK LLP 




Attorney for Appellants 
Attorney Registration No. 43,285 
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Docket No. 8320 

MANAGEMENT DECISION 
MODELING SOFTWARE 
APPLICATIONS 

Field of the Invention 

The present invention relates generally to computer software for solving 
complex business problems, and more particularly, to Management Decision 
Models (MDM) to assist decision-makers in addressing complex business 
5 problems that are quantitatively difficult to solve. The purpose of MDM is to 
provide an approach to reduce time, risk and uncertainties of investing in new 
technologies or design changes by predicting the impact of these new 
technologies before committing to implementation. 

Background of the Invention 

10 Management Decision Models (MDM) are a class of software applications 

providing decision-makers with new information about their business that help 
decision-makers address key business issues. MDM are flexible, data driven, 
software tools used to predict the effect of process, design, or technology changes 
on productivity and other business performance measures, as well as the financial 

15 impact of such changes. MDM may be customized to address questions relating 
to any business domain, including product manufacturing, service industry, and 
retail operations (e.g., grocery front-ends, convenience stores). MDM have 
graphical user interfaces. Components of a MDM include 1) a database 
management module to maintain the application's input data parameters and 

20 output data performance measures; 2) a simulation engine to represent the 
dynamic interaction between the elements of a system, such as, the people, 
equipment, material, information and energy; 3) animation to visualize how the 
system reacts to changes in input parameters; 4) an environmental design layout 



2 



module for calculating physical space requirements to accommodate new 
equipment or process changes; and 5) a financial module which transforms 
operational performance measures into financial metrics including Return on 
Investment (ROI). 

5 The output from a MDM indicates the predicted performance of the 

system using metrics that are the most meaningful to the decision-maker. The 
output includes operational performance measures, such* as, queuing times or 
sizes, equipment utilization, number of stock-outs, and customer system times as 
well as financial metrics, such as ROI, Not Present Value (NPV), and payback. 

10 

Summary of the Invention 

MDM are a class of decision support software applications for assisting 
business management in making strategic business decisions. MDM address 
business problems in a unique way. MDM are flexible, data driven, and 

15 integrated software tools. MDM are flexible, so a user can address an unlimited 
number of issues relating to specific domain applications. MDM are data driven, 
so a user can customize a model to a particular problem by entering the 
appropriate values into the input data parameters. MDM are integrated, so a user 
can apply one or more components of the tool to address business questions. 

20 Another key concept about MDM is that MDM are designed to be usable by 
individuals that are knowledgeable about the application domain and not 
necessarily knowledgeable about the tool's methodology. In summary, MDM 
provide a structured, quantitative approach to address business issues and help 
companies profitably manage and grow their business. 

25 An example of an MDM application is a Branch Effectiveness model 

(BEM). The BEM is a self-contained PC desktop application that allows a bank 
analyst to quantitatively analyze changes to their branch environments. The BEM 
uses simulation to mimic the complex interactions between customers and bank 
resources in three branch environments: Customer Service, Self Service, and 
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Retail Service. The purpose of the model used in the present invention is to 
provide banks with a method to reduce the risk and uncertainties of investing in 
new technologies or design changes by predicting their impact and return before 
committing resources to their acquisition or implementation. 
5 Still other objects and advantages of the present invention will become 

v readily apparent to those skilled in the art from the following detailed description, 
wherein the preferred embodiments of the invention are shown and described, 
simply by way of illustration of the best mode contemplated of carrying out the 
invention. As will be realized, the invention is capable of other and different 
10 embodiments and its several details are capable of modifications in various 
obvious respects, all without departing from the invention. Accordingly, the 
drawings and description thereof are to be regarded as illustrative in nature, and 
not as restrictive. 

15 Brief Description of the Drawings 

The present invention is illustrated by way of example, and not by 
limitation, in the figures of the accompanying drawings, wherein elements having 
the same reference numeral designations represent like elements throughout and 
wherein: 

20 Figure 1 is a high level block diagram of a computer system usable with 

the present invention; 

Figure 1A is a high level logical architecture of an MDM according to the 
present invention; 

Figures IB and 1C are flow diagrams for an MDM model according to the 
25 present invention; 

Figure 2 is a flow diagram over viewing a customer engagement process; 
Figure 3 is a flow diagram over viewing a modeling process; 
Figure 4 depicts a Branch Effectiveness Model main menu form; 



Figure 5 depicts a Branch Effectiveness Model input module form; 
Figure 6 depicts a Create Parameter File form; 
Figure 7 depicts an input module form after creating Scenario Casel; 
Figure 8 depicts Edit Parameter File form; 
Figure 9 depicts an Arrival Rate Schedule form; 
Figure 10 depicts a Customer Decision Matrix Edit form; 
Figure 1 1 depicts a Self Service and Operator Assisted Balk Probabilities 
Edit form; 

Figure 12 depicts a Personnel Schedule Edit form; 
Figure 13 depicts a Counter Transaction Type Probabilities Edit form; 
Figure 14 depicts a Counter Transaction Times Parameter 1 Edit form; 
Figure 15 depicts a Delete Parameter File form; 

Figure 16 depicts a Print Scenario Data Input Dictionary Report for the 
Self Service Branch Model; 

Figure 17 depicts a Rim Simulation Module form; 

Figure 18 depicts an Animation Overview Screen for the Self Service 
Branch Model; 

Figure 19 depicts a Main Menu Screen for the Self Service Branch in 
Animation Mode; 

Figure 20 depicts a Self Service Branch Model Description Screen in 
Animation Mode; 

Figure 21 depicts a Self Service Branch Output Statistics Screen in 
Animation Mode; 

Figure 22 depicts a Self Service Branch Input Values Screen in Animation 

Mode; 

Figure 23 depicts a Self Service Branch Plot of Number of Customers in 
the Branch Screen in Animation Mode; 

Figure 24 depicts an Animation Overview Screen for Customer Service 
Bank Model; 
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Figure 25 depicts an Animation Overview Screen for Retail Store Branch 

Model; 

Figure 26 depicts running a Model Scenario in Analysis Mode; 
Figure 27 depicts completing a Model Scenario in Analysis Mode; 
5 Figure 28 depicts an Output Module form; and 

Figure 29 depicts Performance Statistics Report for the Self Service 
Branch, 

Best Mode for Carrying Out the Invention 

A method and apparatus for information discovery and visualization are 
10 described. In the following description, for purposes of explanation, numerous 
specific details are set forth in order to provide a thorough understanding of the 
present invention. It will be apparent, however, that the present invention may be 
practiced without these specific details* In other instances, well-known structures 
and devices are shown in block diagram form in order to avoid unnecessarily 
1 5 obscuring the present invention. 

Hardware Overview 

Figure 1 is a block diagram illustrating an exemplary computer system 
100 upon which an embodiment of the invention may be implemented. The 
20 present invention is usable with currently available personal computers, mini- 
mainframes and the like. The computer system 100 can be a "presence" as 
described below. 

Computer system 100 includes a bus 102 or other communication 
mechanism for communicating information, and a processor 104 coupled with the 
25 bus 102 for processing information. Computer system 100 also includes a main 
memory 106, such as a random access memory (RAM) or other dynamic storage 
device, coupled to the bus 102 for storing information and instructions to be 
executed by processor 104. Main memory 106 also may be used for storing 
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temporary variables or other intermediate information during execution of 
instructions to be executed by processor 104. Computer system 100 further 
includes a read only memory (ROM) 108 or other static storage device coupled to 
the bus 102 for storing static information and instructions for the processor 104. 
5 A storage device 110, such as a magnetic disk or optical disk, is provided and 
coupled to the bus 102 for storing information and instructions. 

Computer system 100 may be coupled via the bus 102 to a display 112, 
such as a cathode ray tube (CRT) or a flat panel display, for displaying 
information to a computer user. An input device 114, including alphanumeric and 

10 other keys, is coupled to the bus 102 for communicating information and 
command selections to the processor 104. Another type of user input device is 
cursor control 116, such as a mouse, a trackball, or cursor direction keys for 
communicating direction information and command selections to processor 104 
and for controlling cursor movement on the display 112. This input device 

15 typically has two degrees of freedom in two axes, a first axis (e.g., x) and a 
second axis (e.g.,) allowing the device to specify positions in a plane. 

The invention is related to the use of a computer system 100, such as the 
illustrated system, to display a branch effectiveness model. According to one 
embodiment of the invention, the branch effectiveness model and display is 

20 provided by computer system 100 in response to processor 104 executing 
sequences of instructions contained in main memory 106. Such instructions may 
be read into main memory 106 from another computer-readable medium, such as 
storage device 110. However, the computer-readable medium is not limited to 
devices such as storage device 110. For example, the computer-readable medium 

25 may include a floppy disk, a flexible disk, hard disk, magnetic tape, or any other 
magnetic medium, a CD-ROM, any other optical medium, punch cards, paper 
tape, any other physical medium with patterns of holes, a RAM, a PROM, an 
EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave 
embodied in an electrical, electromagnetic, infrared, or optipal signal, or any other 



medium from which a computer can read. Execution of the sequences of 
instructions contained in the main memory 106 causes the processor 104 to 
perform the process steps described below. In alternative embodiments, hard- 
wired circuitry may be used in place of or in combination with computer software 
instructions to implement the invention. Thus, embodiments of the invention are 
not limited to any specific combination of hardware circuitry and software. 

Computer system 100 also includes a communication interface 118 
coupled to the bus 102. Communication interface 108 provides a two-way data 
communication as is known. For example, communication interface 118 may be 
an integrated services digital network (ISDN) card or a modem to provide a data 
communication connection to a corresponding type of telephone line. As another 
example, communication interface 118 may be a local area network (LAN) card 
to provide a data communication connection to a compatible LAN. In the 
preferred embodiment communication interface 118 is coupled to a virtual 
blackboard. Wireless links may also be implemented. In any such 
implementation, communication interface 118 sends and receives electrical, 
electromagnetic or optical signals which carry digital data streams representing 
various types of information. Of particular note, the communications through 
interface 118 may permit transmission or receipt of data used in the branch 
effectiveness model. For example, two or more computer systems 100 may be 
networked together in a conventional manner with each using the communication 
interface 118. 

Network link 120 typically provides data communication through one or 
more networks to other data devices. For example, network link 120 may provide 
a connection through local network 122 to a host computer 124 or to data 
equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn 
provides data communication services through the world wide packet data 
communication services through the world wide packet data communication 
network now commonly referred to as the "Internet" 128. Local network 122 and 
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Internet 128 both use electrical, electromagnetic or optical signals which carry 
digital data streams. The signals through the various networks and the signals on 
network link 120 and through communication interface 118, which carry the 
digital data to and from computer system 100, are exemplary forms of carrier 
5 waves transporting the information. 

Computer system 100 can send messages and receive data, including 
program code, through the network(s), network link 120 and communication 
interface 118. In the Internet example, a server 130 might transmit a requested 
code for an application program through Internet 128, ISP 126, local network 122 
10 and communication interface 118. In accordance with the invention, one such 
downloaded application provides for input and output of data and parameters as 
described herein. 

The received code may be executed by processor 104 as it is received, 
and/or stored in storage device 110, or other non-volatile storage for later 
15 execution. In this manner, computer system 100 may obtain application code in 

i 

the form of a carrier wave. 

Management Decision Modeling Applications 

Management decision modeling applications are called MDMs. An MDM 

20 is comprised of a set of different objects or modules that are integrated together to 
provide new information to a decision maker on how to improve or manage a 
retail or financial service point system at points of transactions between the 
customer and the operation or the system. Examples of MDMs include modeling 
of a grocery store checkout, a bank branch and a post office. MDMs are flexible, 

25 data driven, integrated applications. The analyst that uses the tool would 
customize a specific MDM application to a customer's environment by specifying 
the input parameter values. 

As depicted in Figure 1A, an MDM 160 is comprised of six or more 
different modules. The first module is a database manager module 170 or just a 
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database engine. The database manager module 170 has all the functionality of 
any other database. The User can create data files, add data files, edit data files, 
modify data files, delete data files, and print data files. Microsoft Access can be 
used as the database engine 170. The second module is a simulation engine 172 
5 which, for example, can be Arena Simulation Software available from Systems 
Modeling Corporation. Simulation is a well known methodology. Simulation is 
used for capturing the dynamic interactions between the entities and resources 
within a particular system. The simulation engine 172 contains all the logic that 
mimics the real life system represented. So, for example, the simulation engine 

10 172 can model a detailed dynamic sequence of steps in the process of a customer 
checking out of a grocery store including the steps of having the customer pick an 
item out of the customer's basket, putting the item on the front belt and having the 
item move down the belt, the cashier picking the item up, entering it via scanner 
or keyboard, and placing the item on the back belt All the logic and how it 

15 would be conceptualized is all embedded into the simulation model. In any 
particular MDM application, it might be multiple types of simulations. In fact, 
each one developed thus far has multiple simulation models representing site 
variations of the particular domain of that application. The simulation models are 
the essence of logic of the system that the MDM model represents. 

20 The third module is called the animation module 174 that allows the User 

to visualize what the logic is embodied in the simulation model 172. The 
aniination module 174 provides a visual two dimensional view of the system that 
simulation represents and it shows the movement of various icons corresponding 
to the customers, resources, check stands or ATMs, etc. The software being used 

25 for the animation module 174 is available from Systems Modeling Corporation. 

An environmental design layout module 176 is used to layout the various 
resources used in simulating in modeling a grocery store check out counter, a 
bank branch checkout counter and the like. 
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A financial module 178 is used to determine the financial impact of 
changing the resources used in the simulation. 

A quick assessment module 180 is used to quickly provide an overview to 
the User of the impact of making changes to the resources used in the simulation. 
5 Referring now to Figure IB, a flow diagram illustrating an overview of the 

MDM process according to the present invention is depicted. At step 1000 the 
process is started At step 1010, an MDM application is selected. At step 1012 
an application module is chosen. At step 1014 a model is selected. At step 1016 
an existing scenario is either created or selected. At step 1018 one or more 

10 parameter values are entered. At step 1020 a model with scenario is evoked. At 
step 1022 the output is either viewed, printed or saved. At step 1024 it is decided 
whether to repeat the steps of 1012-1022. If the determination of step 1024 is yes, 
then the application loops back to either step 1012 or step 1014. If the 
determination of step 1024 is no, then the process is completed at step 1026. 

15 Figure 1C is a more detailed flow diagram of step 1010 in Figure IB. At 

step 1100 the process is started. At step 1110 an application module is selected, 
if no application module is selected, then at step 1 1 12 the process is ended. From 
step 1 1 10 the User can select either a quick assessment module 1 1 12 or a design 
layout module 1 1 14. From module 1 1 12 a QA report 1 116 can be generated or an 

20 input module 1118 can be selected. The quick assessment module 1112, the 
design layout module 1114 and the input module 1118 all access an application 
database 1 130. A simulation module 1 140 interacts with the input module 1118. 
The simulation module 1 140 can be used to generate a simulation report 1 142. A 
financial module 1 150 interfaces with the input module 1118 and the application 

25 module 1110. The financial module 1150 can be used to generate a financial 
report 1152. Both the simulation module 1140 and the financial module 1150 
access the application database 1 130. 

Referring now to Figure 2, an overview of a customer engagement process 
is depicted. At step 210 business issues are identified. At step 220 the questions 
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are specified that have to be answered. At step 230 data requirements are 
determined. At step 240 data is collected. At step 250 modeling techniques are 
used to transform data into information. At step 260 the User answers questions 
and makes recommendations based upon the output of the modeling techniques. 
At step 210 the process can be continued in a circular fashion until the modeling 
technique is completed. The Figure 2 diagram is an overview of the MDM 
process. 

Figure 3 is an overview of the modeling process used in Figure 2 and more 
specifically the modeling technique of step 250 in Figure 2. The modeling 
process must be validated and credibility established for the modeling process to 
be effective. First assumptions must be made to be placed into the conceptual 
model 310. The output from the conceptual model is input into a mathematical 
model 320 which includes approximations. The mathematical model is exercised 
and outcomes are predicted by checking the mathematical model against the real 
systems bank branch. Data is collected and the bank branch is observed to 
validate and establish credibility for the mathematical model. 

The BEM Application 

The BEM application provides a bank analyst with a tool that can predict 
their impact of moving from predominately counter based services to self-service 
in a bank branch. As described herein in Figures 4-29, a user guide is described 
instructing a user for using the BEM application. The BEM application is 
included herein as Attachments as follows: Attachment A entitled "SSBModel" 
(pp. 1-112); Attachment B entitled "RSBModel" (pp. 1-94); Attachment C 
entitled "CSBModeP (pp. 1-68); and Attachment D entitled "BEMApp. (pp. 1- 
55). An analyst may use the BEM to identify and recommend alternative business 
methods that affect: 

• Productivity 

• Customer service 
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• Operating costs, and 

• Overall profitability. 

These improvements may result from more efficient labor scheduling, 
number and location of customer service points, or refinements in branch design 
and layout. 

The BEM application provides a Graphical User Interface (GUI) that 
allows a user to: 

• Input and manage data that characterizes a particular branch; 

• Select and run one of the corresponding simulation models; and 

• View and write the simulation results to a file or printer. 

The BEM application represents three different types of branch 
environment: Customer Service, Self Service, and Retail Service. The following 
list of characteristics describes these three environments: 
Customer Service Branch (CSB) 

• prime high street locations 

• current account based, routine transactions 

• counter service based 

• no back office functions 

• 5-20 staff, depending on location' 

• typical banking hours, 9am-3pm, Monday to Friday, maybe Saturday 

• high cost of delivering customer service 
Self Service Branch (SSB) 

• increasing availability of customer service, 24 hours 

• extend customer offerings 

• migration from counter services to self service 

• no back office functions 

• new outlet locations, e,g., shopping malls 

• reduced staff manning 



13 

• meeter/greeter staff role only 

• no formal meeting rooms 

• lower cost of delivering service 
Retail Service Branch (RSB) 

• more aggressive "retail" approach 

• enhanced customer experience 

• building "foot flow 9 ' 

• softer, more informal environmental design 

• staff emphasis on selling and promotion 

• 4 to 6 staff typically 

The BEM application simulates bank operations for a user-defined 
planning period (e.g., a day) by representing customer demands service 
requirements, bank automated resources, travel distances, staffing schedules, and 
other bank procedures for each of the three branch types* Each branch type 
consists of a configuration of service points. The following table shows the 
service points for each branch type and whether the branch type requires operator 
assistance. 
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Module Type 


CSB 


SSB 


RSB 


Staff 


ATM - cash only 
(Fast Cash) 


Yes 


Yes 


Yes 


No 


ATM - cash, balance, 
statements, deposits 
(Multi ATM) 


Yes 


Yes 


Yes 


No 


ATM - general 


Yes 


Yes 


Yes 


No 


Deposits - personal 
(automated) 


Yes 


Yes 


Yes 


No 


Deposits - business 
(automated) 


Yes 


Yes 


Yes 


No 


Deposits - Postbox 


Yes 


Yes 


Yes 


No 


Change machine 


No 


Yes 


Yes 


No 


Kiosk Bank only 


No 


Yes 


Yes 


No 


Kiosk Other 


No 


Yes 


Yes 


No 


Writing Desk 


Yes 


Yes 


Yes 


No 


Telephones 


No 


Yes 


Yes 


No 


Reception desk 


Yes 


Yes 


Yes 


Yes 


Meeting room - 
enclosed 


Yes 


No 


Yes 


Yes 


Cashier counter 
positions 


Yes 


No 


No 


Yes 



Excluded from the BEM module are branch back office functions. The 
BEM module does not represent staff requirements to carry out any form of 
5 service on self service module types, e.g., periodically empty envelopes from a 
deposit machine. 

The BEM module includes Input, Run Simulation and Output Modules. 
The Input module allows the User to create and manage input data 
scenarios that characterize the configuration and logic in a simulation model. For 
10 example, the User may specify the number of tellers or ATM machines, service 
times or service operations, customer arrival patterns or service requirements. 
The Data Input Dictionary (DID) for each simulation model lists and defines the 
parameters used in each model. Appendix A contains the DID reports for each 
model. 
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The Run Simulation Module allows the User to select one of the three 
simulation models and an input data parameter file that defines the scenario the 
User wants to analyze. Each of the summation models can run in two modes: 
Demo and Analysis, The Demo mode for a simulation has the animation turned 
5 on; the Analysis mode has the animation turned off. With the animation off, the 
models execute much faster allowing the User to conduct more statistically sound 
experiments and evaluate more scenarios in a shorter time period. A model with 
the animation turned on is more effective for understanding and communicating 
the model's results. In many cases the animation provides a visual check that the 

10 model is running the way the User expects. There are also several screen views 
that provide additional insight when the model is run with animation. 

The Output Module allows the User to view and write results after running 
a simulation model to a file or printer. The performance measures calculated by 
each model include queue size, queue time, dwell time, transaction counts, and 

15 utilization for all service points in the scenario. The models also outputs bank 
level measures such as number and time a customer spends in the bank, total 
number of customers and transactions processed, balking, and labor times. 

The BEM module is a powerful analysis tool that can help a bank analyst 

design, manage, and improve a branch's configuration and operations. The model 
20 predicts the operational impact of changes to a branch environment thereby 

allowing the bank to reduce the time, uncertainty, and risk when making these 

types of business decisions. 

As used herein, the following conventions are used to describe screens, 

their objects and user operations. A full screen window is referred to as a form. 
25 The form's title is used to reference the window. The button options of a form are 

referenced using bold letters and file names in Italics. We also use the phase 

"click" or "select" interchangeably to describe the User operation of evoking a 

form's option using a mouse or other point device. 
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Figure 4 is a display of the Main Menu of the BEM module. From this 
form, the User can enter an Input Module 410, a Run Simulation Module 420 or 
Output Module 430 by selecting the corresponding button with their mouse or 
other pointing device. 

5 When finished, the User closes the BEM application by selecting a Quit 

Application button 440. This is the only form that has the Quit Application 440 
button, so the User must return to the Main Menu to close the BEM tool. 

Figure 5 depicts an input module form 500. The Input Module form 
depicted in Figure 5 allows the User to create, save, edit, delete and print input 

10 parameter files that specify model scenarios. The User can also run a simulation 
scenario with and without animation from the input module form 500. The User 
can perform these operations by first selecting the type of model they wish to run 
in a Models table 510. After choosing the simulation model, the Scenarios table 
530 will display the scenarios files available for that model. The Models table 

15 includes the previously described Self Service Branch Model 1 512, a Counter 
Service Branch Model 1 514 and a Retail Service Branch Model 1 516. Each 
simulation model has its own set of input parameter files. The User may then 
select the input parameter file the User wants to work with (i.e., edit, delete, print 
or run). To select a model or scenario, the User clicks in the Model or 512, 514, 

20 516 or scenario name field 532 or on the small rectangle area of the left of these 
fields 522, 524, 526 and 542, respectively. 

Figure 5 shows the selection of the Self Service Branch Model 512 and the 
Default scenario 532. The User does not have to select a scenario before selecting 
the Create Scenarios button 550. The User will have the opportunity to select a 

25 scenario from which to create a new scenario on a Create Parameter File form 600 
discussed below. If the User wants to run a simulation model with animation, 
check (i.e., click the left button on your mouse while positioned over the check 
box 85) the Animation box 585 before selecting the Run Simulation button 580. 
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When installed on the computer system 100, the BEM module includes on 
Default scenario for each simulation model The values in the Default scenarios 
are from industry composite data collected. 

Appendix A provides a list of the parameter values in the default 
5 scenarios. 

The User can create a new scenario file by selecting the Create Scenario 
button 550 from the Input Module 410. 

Figure 6 depicts the Create Parameter File form 600. To create a scenario, 
the User selects the existing file that the User wants to use to crate the new file 

10 from in the list of scenarios in the center of the Create Parameter File form 600, 
A parameter file scroll bar (not shown) will display to the right of the list when 
there are more than four scenarios for a model. A name for a new scenario is 
entered by positioning the cursor in the Scenario Name field 620 and using the 
keyboard number to type in the name. The BEM module does not allow duplicate 

15 scenario names for a simulation model. The Scenario Name field 620 can be up 
to 30 characters (including blank spaces). The User can also enter an optional 
Scenario Description of up to 55 characters to further describe the parameter file. 

After entering the Scenario Name in a Scenario name field 620 and 
optional description in a Scenario Description field 630, the User should select a 

20 Create and Return button 610 (or press Alt-C) to create the scenario file. The 
application will prompt the User to confirm their selection before returning to the 
Input Module form 500. Figure 6 illustrates the scenario file called Case 1 will be 
created by this process. The other option one could take from this form is a 
Return Without Creating button 615 that returns the User to the Input Module 

25 form 500 without creating a file. The scenario tables 530 is displayed listing 
scenario names and scenario descriptions available to be cloned. 

Figure 7 depicts the Input Module form after the creation of scenario Case 
1 750, A scroll bar (not shown) will display to the right of the Scenarios list when 
there are more than eight scenarios for a model. 
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Each of the simulation models in the BEM application has its own set of 
data parameters the User can control to create a scenario. A model's Data Input 
Dictionary (DID) defines the model's input parameters and their properties, i.e., 
parameter values, ranges, and what each parameter controls in a model scenario. 
5 The User can view or print a model's DID using a Print Scenario button 575 from 
the Input Module form 500 (or edit forms for non-scalar parameters). The DID 
provides the following information for each parameter. 

Parameter: The parameter column provides a brief description of how 
the model uses the input parameter data. If the parameter 
1 0 field contains the word "ARRAY" it means that it has more 

than one value assigned to it. For example, the User can 
enter up to 96 values for the parameter representing the 
expected number of arrivals per % hour in 15-minute time 
intervals for a 24-hour day. 
15 Value: The value column displays the current data value assigned 

to each parameter. A parameter with more than one value 
will not display a value in this field, i.e., the field is blank. 
Parameters of this type are edited using an additional edit 
form. 

20 Range: The range column defines the range of values and the units 

for the parameter. 

Description: The description column provides a more detailed 

description of the parameter and its use in the model. 
The following table shows the number of parameters and values under the 
25 control of the User for each of the BEM models. 



Simulation Model 


Number of 
Parameters 


Number of 
Values 


Customer Service Branch Model 


59 


458 


Self Service Branch Model 


66 


409 


Retail Service Branch Model 


70 


489 
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The parameters for each model are divided into five categories to make them 
easier to learn and easier to change their values- The eight categories are as 
follows: 

5 1. Configuration 

2. Customer Demand and Routing 

3. Labor Schedules 

4. Transaction Characteristics 

5. Simulation Model Parameters 

10 The Configuration category contains parameters that define the length and 
resources in a scenario, e.g., the number and type of ATMs, etc. The length of a 
scenario for any of the models can be up to 24 hours. 

The Customer Demand and Routing category has parameters that specify the 
expected number of customer arrivals (i.e., footfalls) by time of day, customer 

15 routing between service points within a branch, and balking criteria. The BEM 
module uses a random sampling process (non-homogeneous Poisson arrival 
process) to generate the arrival times and another random sampling process to 
determine the sequence of service points a customer visits once they enter the 
branch. The User controls how many customers arrive and their routing within 

20 the bank using the arrival rate and customer decision matrix parameters. 

Parameters in the Schedules category for the BEM module allow the User to 
enter Tellers, Platform personnel, and Meeter-Greeter schedules in 30-minute 
intervals during a scenario. 

The Transaction Characteristics category contains parameters that govern the 
25 dwell time parameters by resource type and the number of transactions per 
customer visit per resource by resource type. The dwell time at a resource is 
defined as the time interval between when a customer initiates a service request 
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and until they depart the resource. It should be noted that a customer's dwell time 
is not necessarily the same as the transaction time at a resource because a 
customer may perform more than one transaction at a service point per visit. 

For most dwell time events, the User needs to enter two parameter values. In 
5 the BEM module, the first parameter specifies the mean and the second parameter 
specifies the standard deviation of the event time distribution. For example, in the 
default scenarios for SSB, the mean and standard deviation for the dwell time at a 
Cash-Only ATM are 52 and 23 seconds, respectively. 

Also, the User will need to specify the number of transactions per visit for 
10 each service point. The default values for these parameters are one. 

There are only three parameters in this category for each model. They are 
<fi Number of replications", "Stream number identifier", and "Check input option 
identifier". In most applications, the User will not need to change the values of 
these parameters. If the User wishes more precision in the model's estimates of 

15 the mean performance measures, the User should increase the value of "Number 
of replications". We recommend that the User does not reduce the value of this 
parameter below 30 when using the model results to make inferences about the 
checkstand or front-end design. Changing the value of the "Stream number 
identifier" will run the scenario using a different sequence of random numbers. 

20 Finally, the "Check input option identifier" specifies whether the parameter 
values for a scenario file are written to a file: c:\Arena Viewer\BEA4\BEMChk.out. 
The purpose of this file is to verify input parameter values or for technical 
support. 

To modify the parameter values for a scenario, the User should select the Edit 
25 Scenario button 560 on the Input Module. 

Figure 8 depicts an Edit Parameter File form 800. The Edit Parameter File 
form 800 allows the User to view or change the values for each parameter in the 
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scenario files created by the User. Recall the User can not change the values in a 
model's Default scenario. 

Each time (he User enters this form, an edit table 810 displays the full set 
of parameters in the DID, The edit table 810 includes a parameter column 850, a 
value column 855, a range column 860 and a description column 865. The User 
can use the scroll bar 815 to the right of the edit table 810 to browse through the 
full set Alternatively, the User can view only a subset of the parameters 
corresponding to a particular category by clicking on a category button in a 
Parameter Categories section 820. The parameter categories are represented by 
buttons including configuration 822, customer demand and routing 824, 
transaction characteristics 826, labor schedule 828 and model parameters 830. 

There are two approaches for editing a parameter's value(s) depending on 
whether the parameter ha a single value (called a scalar parameter) or has multiple 
values (called a non-scalar parameter or an ARRAY). To edit the value for a 
scalar parameter, the User selects the cell in the Value column 855 of the edit 
table 810 for the parameter that the user wants to change and enters the new 
value. For example, to change the scenario Start Time parameter from 9 a.m. to 
8:30 a.m., in Figure 9, the User selects the cell containing the value of 9 and type 
in 8.5. Note the Start Time and End Time parameters are in units of hours from 
12 midnight. When changing values, the User should make sure the new value is 
within the allowable range displayed in the Range column 860 for the parameter. 
If the User enters a value outside the allowable range, the BEM module will 
remind the User with a warning message. 

To edit the values for a non-scalar parameter, the User must click on the small 
rectangle icon just to the left of the Parameter field. This action will evoke a new 
form that will allow the User to edit each value for the parameter. A non-scalar 
parameter will have the word "Array" in the parameter column and no value in 
the Value column. . 
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There are ten non-scalar parameters in the BEM module. The following is a 
list of these ten non-scalar parameters: 

1 . Number of arrivals per hour in 15 -minute intervals 

2. Customer Decision Matrix 

5 3. Self-service balk probabilities 

4. Operator assisted balk probabilities 

5. Schedule of Tellers 

6. Schedule of Platform personnel 

7. Schedule of Meeter-Greeters 

10 8. Counter transaction type probabilities 

9. Counter transaction times parameter 1 

10. Counter transaction times parameter 2 

< 

After the User clicks on the rectangle icon 842, 844, 846, 848 adjacent to the 
left side of the Parameter column 850, the BEM module will open a new form that 
15 allows the User to modify the parameter's values. The edit forms are described 
below for these non-scalar parameters. 

The Arrival Rate Schedule form allows the User to change the values for the 
parameter that describes the rate at which customers arrive to the branch. The 
model uses these rates to randomly generate customer arrival times throughout the 

20 simulation scenario. Figure 9 depicts the form for editing the "expected number 
of arrivals per hour in 15-minute intervals" 

An edit table in the Arrival Rate Schedule form 1000 lists values from 
12:01a.m. to 12:00 p.m. in 15-minute intervals in a time interval column 1040. 
To change a value, the User scrolls to the time interval using a scroll bar 1015 that 

25 the User wants to edit, selects the corresponding cell in a Number of Arrivals 
columnlOSO and enters the new value. The units for the values entered into this 
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parameter are number of arrivals per hour in 15 minutes not the number of 
arrivals in 15 minutes. 

The User must understand this important difference to prevent running a 
scenario with a different customer arrival pattern then the User intended to run. 
5 For example, if the User wants to represent 100 customers per hour from 9:00 to 
9:30 a.m., and 150 customers per hour from 9:30 to 10:00 a.m. then the entries 
should be: 

9:01-9:15 a.m. 100 

9;16-9:30a.m.l00 
10 9:31-9:45 a.m. 150 

9;46-10:00 a.m. 150 

The model ignores values entered in the Number of Arrivals column 1050 
before and after the time intervals specified by the Start Time and End Time 
parameters, respectively. 
15 There are two options from this form, either a Print Schedule button 1060 

or Return to Edit form 1065. The Print Schedule button 1060 creates a report 
containing the arrival rate schedule and displays it on the screen. The User can 
then send the report to a printer or save it to a file in a variety of data formats. 

Figure 10 depicts a Customer Decision Matrix Parameter form 1000 used 
20 to edit the Customer Decision Matrix Parameter. This Customer Decision Matrix 
parameter defines the probability a customer visits a particular sequence of 
service points when the customer enters the bank. The logic represented by this 
approach is referred to as probabilistic routing. For example, Figure 10 illustrates 
that 2% of the entering customers will use a Business Deposit machine as the first 
25 service point the customer visits. After finishing at the Business Deposit 
machine, 14% go onto a Multifunction ATM (i.e., ATMMulti) machine and 86% 
exit the bank (the horizontal scroll must be used to se the 0.86 in the Exit 
column). 

Two important things to remember when modifying the CDM: 
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1 ) The row probabilities must sum to 1 

2) The only valid entries for a cell are between 0.0 to 1 .0 

The Customer Decision Matrix 1000 includes "from" rows and "to" 
columns. The "from" rows are entrance 1012, ATM cash 1014, ATMMulti 1016, 
5 ATMGen 1018, DepPer 1020, DepBus 1022, DepPost 1024, Change 1026 and 
KioskBank 1028. The "to" columns include entrance 1070, ATMCash 1072, 
ATMMulti 1074, ATMGen 1076, DepPer 1078, DepBus 1080, DepPost 1082, 
Change 1 084, KioskBank 1 086 and KioskOther 1 088. 

The BEM module checks to make sure the rows sum to one and will issue 
10 a warning message if they do not. If this occurs, then the User will have to find 
the row that violates this requirement and make the necessary corrections. The 
BEM module does not check if the data entered is within the range of 0.0 to 1.0, 
so it incumbent on the User to adhere to this requirement 

There are two options from this form, either a Print Matrix button 1060 or 
15 a Return to Previous Form button 1065. The Print Matrix button 1060 creates a 
report containing the CDM and displays it on the screen. The User can then send 
the report to a printer or save it to a file in a variety of data formats. The Return 
to Previous Form 1065 returns the User back to the Edit Parameter File form 800. 
Figure 1 1 depicts a form to edit the Self-Service and Operator Assisted 
20 Balk Probabilities parameters. These parameters specify the probability that a 
new customer balks (leaves without receiving service) from a self-service or 
operator assisted resource when its queue size reaches or exceeds the value 
entered in the balk queue size threshold parameters. Operator assisted resources 
tab 1120 are the Counter Positions, Reception Desk, and Meeting Rooms. Once 
25 the User has entered this form, the User can select the tab of the other parameter 
and edit its values before returning to the Edit Parameter File form 800. 

The balk probabilities indicate the probability that a newly arriving 
customer will not join the queue when its size reaches the threshold queue size or 
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greater. For example, assume there are 5 people waiting in line to use a single 
Kiosk-Bank machine and the self-service threshold queue size parameter is set to 
4 and the balk probabilities are those displayed in Figure 11. Then, say the next 
event is the arrival of a new customer who wishes to use the Kiosk-Bank. In this 
5 case, the new customer would balk with probability 0.5. For this example, a 
customer would never balk if the queue size is less than 4 and the queue size 
would never exceed 7 (because the Threshold Queue Size+3 is 1.0). If the queue 
size would get larger than the Threshold Queue Size+3, then the model would use 
the probability in this last cell for the probability that a customer balks. 

10 There are two options from this form, either a Print Schedules button 1 160 

or Return to Previous Form button 1 165. The Print Schedules button 1 1 60 creates 
a report containing the balk probabilities for both resource types and displays it on 
the screen. The User can then send the report to a printer or save it to a file in a 
variety of data formats. The Return to Previous Form button 1 165 returns the 

15 User back to the Edit Parameter File form 800. 

Figure 12 depicts a Personnel Schedules edit form 1200. The Labor 
Schedule category contains three parameters: 

1) Schedule of Tellers 

2) Schedule of Platform personnel 

20 3) Schedule of Meeter-Greeters 

These three parameters allow the User to enter the number of staff for the 
three types of labor in 30-minute intervals during a scenario. 

The Personnel Schedules edit form includes parameter tabs for Platform 
Personnel 1210, Tellers 1220, Meeter Greeters 1230 and All Personnel 1240. 
25 Figure 12 illustrates the current active parameter is the "Schedule of Tellers". As 
depicted in Figure 12, an edit table 1210 includes a Time Interval column 1250 in 
half hour increments and a Tellers column 1260. After the User enters this form 
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from the Edit Parameter File form 800 for any of the three parameters, the User 
can edit the values for the other parameters by selecting the corresponding 
, parameter tab. The tab labeled All Personnel 1240 displays an edit table for all 
^ three parameters at the same time. 

5 The BEM module requires that an operator-assisted resource have at least 

one staff member in order to provide service to a customer. If one is not available 
and the resource is in a customer's route, then the customer will skip the resource 
and move on to the next step in their routing sequence. The only other 
requirement is the User should enter only nonnegative integer values. The model 

10 ignores values entered in the schedules before and after the time intervals 
indicated by the Start Time and End Time parameters, respectively. Also, the 
User should not enter a value in a schedule larger than the number of service point 
locations. For example, if the number of Reception Desks is one, then any 
entering a value greater than one in the "Schedule of Meeter-Greeters" will result 

15 in the same performance as entering a value of one. The only difference is that 
the User has more scheduled Meeter-Greeter time. 

After the User finishes editing the values in this form, the User can select 
one of two options, either a Print Schedule button 1260 or a Return to Edit form 
button 1265. The Print Schedule button 1260 creates a report containing the 
20 schedules for all three parameters by time of day and displays it on the screen. 
The User can than send the report to a printer or save it to a file in a variety of 
data formats. 

Counter transaction type probabilities parameters are displayed in Figure 
13 as form 1300. The BEM module allows the User to specify up to five different 
25 types of transactions that a customer can receive at a Counter Position. The 
reason for this flexibility is to allow the User to represent counter transaction in 
greater detail. This feature would be useful if transaction type counts are 
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important or if there is significant differences between transaction times by type. 
For example, five transaction types might be the following: 

1) House items cashed 

2) Remittance check cashed 
5 3) Deposit (credit) with cash 

4) Deposit without cash 

5) Other, e.g., currency exchange, traveler's checks, etc. 

If this added detail is unnecessary, then the User may represent just one counter 
transaction type by entering the values into the counter transaction type 
10 probabilities. 

Figure 14 depicts a form 1400 to edit the "Counter transaction times 
parameter 1" is shown in Figure 14. A "Counter transaction times parameter 2" 
parameter is similar to this form and is not discussed herein. 

Similar to the other non-scalar parameter edit forms, the User can select 
u 15 one of two options after the User finishes editing the values in this form, either a 
Print Values button 1460 or a Return to Previous form button 1465. The Print 
Values 1460 button creates a report containing the values for all three counter 
transaction parameters and displays it on the screen. The User can than send the 
report to a printer or save it to a file in a variety of data formats. 
20 The User can delete scenario files created by the User by selecting the 

scenario on the Input Module form and evoking the Delete Scenario option. 
Performing this action will open the Delete Parameter File form 1 500 displayed in 
Figure 15. 

There are two options from this form: a Delete and Return button 1500 
25 and a Return Without Deleting button 1565. If the User selects the Delete and 
Return button 1560, then the BEM module opens a window which prompts the 
User to confirm the request to delete the scenario file. Selecting OK to the 
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confirmation will delete the scenario file and return the User to the Input Module 
Form 500. Selecting CANCEL on the confirmation will return the User to the 
Delete Parameter File form 800 without deleting the file. The Return Without 
Deleting option 1565 returns the User to the Input Module form 500 without 
5 deleting the scenario file. 

The User can display a model's DID by selecting the Print Scenario option 
from the Input Module form 500. Figure 16 depicts the first page of the DID for 
the SSB model. The User can use the control buttons at the top of this window to: 
1 . Page through the report 
10 2. Print the report to the default Windows 95™ printer, or 

3. Save the report to a disk file in the name of User's choice and in a 

variety of data formats* 
After the User finishes with the DID report, the User can close the report 
window as one would with any other Windows 95™ window, e.g., click on the 
1 5 "X" icon in the upper right hand corner. 

The Print Scenario option 575 from the Input Module 500 will create and 
display a report of only a model's scalar parameters and their values. To generate 
a report containing the values for non-scalar parameters, the User needs to select 
the print option button on the non-scalar parameter edit form. For example, 
20 selecting the Print Schedule 1260 from the Personnel Schedule edit form 1200 
will print the values for the three labor schedule parameters. 

The User can run a simulation model from the Input Module form 500 or 
the Run Simulation Module form 1700 discussed below. There is no difference 
between running a model from either location in the BEM module. In each case, 
25 the User selects the model and scenario the User wishes to run and then the User 
starts the simulation by selecting the Run Simulation button 580. Checking the 
Animation box 585, the Run Simulation button 580 will turn on the animation. 

The User can run existing scenario files from the Run Simulation Module 
form 1700 depicted in Figure 17. A models table 1710 includes the following 
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models: a Self Service Branch Model 1 1712, a Counter Service Branch Model 1 
1714 and a Retail Service Branch model 1 1716 activated by rectangular boxes 
1722, 1724 and 1726, respectively. A scenarios table 1730 includes a Default 
Scenario 1732 and a Case 1 Scenario activated by rectangular boxes 1742 and 
5 1 744, respectively. 

There are three options from this form: a Return to Main Menu button 
1770, a Print Scenario button 1775 and a Run Simulation button 1780. The first 
button 1770 will generate a report containing a model's DID and display it on the 
screen. Figure 17 illustrates the DID report for the FEM1 model. The User can 
10 then send the report to a printer, save the report to a disk file, or close the report 
and return to the Run Module form. The Run Simulation options will start 
running the model and scenario selected in the Models and Scenarios tables of 
this form. 

To run a model with the animation on, the User checks the animation box 
15 1785 before selecting the Run Simulation button 1780. This action launches the 
Arena Viewer™ application, loads the model, and starts to run the scenario. 
Figure 18 illustrates the animation overview screen of the SSB model 

In animation mode, the model scenario will start running, i.e., Go, 
automatically. To pause the model, the User needs to click on the Pause button, 
20 i.e., the button with two vertical lines, "||". The User may want to pause a model, 
for example, to describe the scenario to their audience or check to make sure the 
scenario status variables displayed on the screen appear correct. When the User is 
ready to start the model again, they select the Go button, i.e., the right arrow 
button, "o". To end the model, the user needs to click on the Pause button, 
25 and then the End button, i.e., the button with a rectangle. The User can restart the 
model after a Pause or begin it again after they select the Pause and End button, 
by selecting the Go button. When the User finishes demonstrating the model or is 
confident the model scenario appears correct, they need to End the simulation 
scenario, close the Arena Viewer™ application, and return to the BEM 
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application. The simplest method to close the Arena Viewer™ application is to 
click on the X icon in the upper right hand corner of the screen. 

One important reason to first run a model scenario in animation mode is 
the simulation models perform additional checks on whether the parameter values 
5 for a scenario are feasible or not. If an error is found, the model will stop 
prematurely (i.e., before the model completes the specified number of 
replications). If the model stops, Arena Viewer™ will display a window asking if 
the User would like to see the model's results. Answer Yes to this prompt and a 
window displaying a text file will display on the screen. The first line of this text 

10 file will contain an error message that indicates why the model stopped. The User 
should take note of the error message, close the text file window, close the Arena 
Viewer™, and go into the Input Module and make the correction to the input 
scenario indicated by the error message. If the User is in animation mode and the 
model scenario runs to completion, then the User should click the No button on 

15 the prompt to see the model's results, close the Arena Viewer™ application, and 
go into the Output Module to see the results. 

The present invention has also set up several screen views in each of the 
simulation models to help the User better understand and communicate the 
model's results. One can display these screen views only when a model is run in 

20 animation mode. Arena Viewer™ lists the screen views for each model when the 
User presses the "m" key (lower case) on the keyboard. Figure 18 shows the 
screen views available in the SSB Model. 

The User can switch between screen views by entering the lower case 
letter corresponding to the screen view title. For example, pressing the "a" key 

25 switches the view back to the animation overview screen displayed in Figure 18. 
Pressing the "s" key displays a close-up view of the branch shown in Figure 18. 
Figure 20 displays a screen view that gives a summary description of the model. 
Figure 21 depicts the screen view displayed when pressing "o". This screen 
shows the current value of some of the output performance measures reported by 
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the model Figure 22 shows a view that contains the values of several key 
scenario parameters by pressing "I". Lastly, Figure 23 shows a graph of the 
number of customer in the branch as a function of time of day. 

When the User is ready to run simulation experiments to analyze the 
5 impact of certain design, procedure, or technology changes on branch 
performance, the User should do so with the animation off. This is referred as an 
analysis mode of running scenarios. When the animation is off, the models 
execute much faster allowing the User to conduct more statistically sound 
experiments. The User can also evaluate many more scenarios in a shorter time 
10 period. 

To run a scenario in analysis mode, the User selects the Run Simulation 
button 1780 on the Run Simulation module form 1700 with the Animation box 
1785 left unchecked. After a slight delay to initialize the model, a window will 
appear displaying the current number of replications completed out of the total 

1 5 number of replication you specified in the input parameter 4C Number of simulation 
replications". For example, Figure 26 illustrates the model has processed 2 out of 
30 replications of this scenario. 

When the model completes all the replications, the BEM module will 
display a window to ask if you would like to see the results. Figure 27 displays an 

20 example of this window. Selecting Yes will cause the BEM module to go to the 
Output Module form 500. Selecting No will return the BEM module to the Run 
Simulation Module form 1700. 

Output Mode 

25 The BEM module will generate one standard set of output performance 

measures each time the User runs a simulation model. There are up to 107 
performance measures in this set. These measures include throughput, balk 
counts, dwell times, queue sizes and times, and resource utilization. Appendix B 
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provides the performance measures reports for the Default Scenarios for each of 
the models. 

Figure 28 shows the Output Module forms. To view the report, simply 
use a scroll bar 2815 to the right of a Performance Measure table 2810. To view 
5 performance measures for a particular model resource, click the resource button a 
Resource Type section. In Figure 28, the set of buttons 2820 includes an All 
Measures button 2822, a Branch button 2824, an ATM button 2826, a Deposit 
button 2828, a Counter button 2830, a Labor button 2832, a Change button 2834, 
a Kiosk button 2836, a Meeting Room button 2838, a Phone button 2840, a 

1 0 Reception button 2892 and a Writing Desk button 2844. 

The Output Module forms also display the Model Name in box 2860, 
Scenario Name in box 2862, and the number of replications (e.g., 30 in Figure 28 
in box 2850) that were used to generate the report The number of replications 
indicates the number of times the scenario was repeated. The purpose for 

15 replicating a scenario is to obtain sufficient number of independent and identically 
distributed observations so one can estimate the performance measures, e.g., 
average number of customer in the bank, with enough precision to make valid 
inferences. In general, increasing the number of replications increases the 
precision (reduces the standard error) in estimating the average performance 

20 measure. 

The performance measures report contains estimates for the average, 
.standard error, minimum, and maximum value for each performance measure. 
The minimum and maximum values are the minimum and maximum values of the 
summarized performance measure at the end of a replication and not necessarily 
25 the minimum and maximum value during a replication. The standard error 
statistic provides a measure of error for how well the average value reported by 
the model estimates "the true*' average value. In general, one can view **the true" 
average value to fall within plus or minus two times the standard error value 
around the estimated average. 
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An alternative way to view a performance measures report is to select the 
Print Results button. This action creates a performance measures report document 
and displays it oh the screen. Figure 29 illustrates the report for the SSB model 
The User can use the control buttons at the top of this form to page through the 
5 report, print it, or save it to a disk file in various data formats. 

The other two options for the output Module form are Return to Input 
Module and Return to Main Menu. 

The BEM module does not save simulation results from previous 
simulation runs. So, the User will need to send the report to a printer or write it to 
10 a file to retain the results each time they run a scenario. Writing the report to a 
file and reading it into a spreadsheet application such as Excel™ or Lotus™ 
makes it easier to consolidate output reports comparing system performance 
across simulation scenario. 

It shall now be apparent that a BEM module has been described. 

15 Advantageously, the BEM module is a self-contained PC desktop application that 
allows a bank consultant to quantitatively analyze changes to their branch 
environments. The BEM module uses simulation to mimic the complex 
interactions between customers and bank resources in three branch environments: 
Customer Service, Self Service, and Retail Service. The goal of the present 

20 invention is to provide a bank consultant with a tool that can predict the impact of 
new branch layouts and design changes before a bank commits to their 
implementation. The BEM module will provide bank managers with: 

1) New information about their business which will help them address 
key business issues, and 

25 2) A strategic planning tool to reduce the time, risk, and uncertainties of 

investing in new technologies or design changes. 

Another MDM application is called a Lane and Front End Effectiveness 
Model (LFEM). The LFEM is a self-contained PC desktop application that 
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allows an analyst to quantitatively predict the impact of changes to their checkout 
operations. This application, according to the present invention, includes four 
simulation models representing the complex interactions between customers, staff 
and checkstand resources. Three of these models are detailed lane models and the 
5 fourth is a store front-end checkout model. An analyst can use the LFEM to 
evaluate, in detail, different checkstand configurations and transaction processes 
and the effect these changes have on overall front-end performance. The purpose 
of this application is to provide retailers with timely information to reduce the risk 
and uncertainties of investing in new technologies or design changes by 

10 predicting their impact and return before committing resources to their acquisition 
or implementation. The LFEM application is included herein as attachments as 
follows: Attachment E entitled "LaneModel" (pp. 1-151); Attachment F entitled 
"Front End Model (pp. 1-101); and Attachment G entitled "LFEMapp" (pp. 1-95). 
It will be readily seen by one of ordinary skill in the art that the present 

15 invention fulfills all of the objects set forth above. After reading the foregoing 
specification, one of ordinary skill will be able to affect various changes, 
substitutions of equivalents and various other aspects of the invention as broadly 
disclosed herein. It is therefore intended that the protection granted hereon be 
limited only by the definition contained in the appended claims and equivalents 

20 thereof. 
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What is claimed is: 

L A method of providing output to predict the impact of changes to 
retail and financial customer services points using management decision models, 
comprising: 

listing categories of parameters with each parameter representing an 
5 aspect of a business operation being modeled; 

choosing at least some of the parameters to describe a particular business 
scenario; 

assigning values to the chosen parameters; 

invoking at least one module in a management decision module to provide 
10 output to a user. 

2. The method of claim 1 , wherein the parameters include: 
a demand category; 

a configuration category; 
a transaction characteristic's category; 
5 a system logic parameter's category; 

a model category; and 
a financial category. 

3. The method of claim 1, wherein the output includes one of 
quantative information and visual information. 

4. The method of claim 3, wherein the quantative information is in 
the form of a report and the visual information is an animation. 



36 



5. The method of claim 4, including one or more of the following 
modules: a database management module, a simulation engine, an animation 
module, an environmental design layout module, financial module and a quick 
assessment module. 

6. The method of claim 2, wherein the output includes one of 
quantative information and visual information. 

7. The method of claim 6, wherein the quantative information is in 
the form of a report and the visual information is an animation. 

8. The method of claim 2, comprising changing the assigned values. 

9. A method of providing output to predict the impact of changes to a 
bank branch using a branch effectiveness model, comprising: 

listing categories of parameters with each parameter representing an 
aspect of a bank branch being modeled; 
5 choosing at least some of the parameters to describe a particular business 

scenario; 

assigning values to the chosen parameters; 

invoking at least one module in the branch effectiveness model to provide 
output to a user. 

10. A method of providing output to predict the impact of changes to a 
bank branch using a branch effectiveness model, comprising: 

selecting an application from the branch effectiveness model; 
selecting a model type from the branch effectiveness model; 
5 choosing a subset of parameters from the model type; 

assigning values to the chosen parameters; and 
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invoking at least module in the branch effectiveness module to provide 
output to a user. 

11. A method of providing output to predict the impact of changes to 
retail and financial customer service points using management decision models, 
comprising: 

listing categories of parameters with selecting an application from 
5 management decision models; 

selecting a model type from the selected application; 
choosing a subset of parameters from the selected model type; 
assigning values to the chosen parameters; and 

invoking at least one module in the selected application to provide output 
10 to a user. 

12. The method of claim 11, comprising selecting a model from the 
selected model type. 

t 

13. The method of claim 11, wherein the management decision model 
includes a database management module, a simulation engine, an animation 
module, an environmental design layout model, a financial module and a quick 
assessment module. 

14. The method of claim 11, wherein the output includes one of 
quantative information and visual information. 

15. The method of claim 14, wherein the quantative information is in 
the form of a report and the visual information is an animation. 

1 6. The method of claim 1 1 , comprising changing the assigned values. 
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1 7. The method of claim 1 1 , wherein the parameters include: 

a demand category; 

a configuration category; 

a transaction characteristic's category; 

a system logic parameter's category; 

a model category; and 

a financial category. 
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United States Patent and Trademark Office 



Commissioner ;FQR Patents 
United States Patent and Trademark Office 

WASHINGTON. D.C. 20231 

www.uspto.gov 

I APPLICATION NUMBER | FILING DATE | GRP ART UNIT | FIL FEE REC'D | ATTY.D0CKET,N0| DRAWINGS | TOT CLAIMS | INDCLAIMs"| 

09/653,196 08/31/2000 2123 948 8320.10- 22 26 1 

CONFIRMATION NO. 4698 
CORRECTED FILING RECEIPT J 

Received IHMIIUH1HI11IIIII1 

NcTCSn APRS^nn, •»«-»-»»»• 

101 West Schantz Avenue HrK * U tUUl 

Dayton, OH 45479-0001 

\ AW DEPARTMENT 

Date Mailed: 04/16/2001 

Receipt is acknowledged of this nonprovisional Patent Application. It will be considered in its order and you will 
be notified as to the results of the examination. Be sure to provide the U.S. APPLICATION NUMBER, FILING 
DATE, NAME OF APPLICANT, and TITLE OF INVENTION when inquiring about this application. Fees 
transmitted by check or draft are subject to collection. Please verify the accuracy of die data presented on this 
receipt. If an error is noted on this Filing Receipt, please write to the Office of Initial Patent 
Examination's Customer Service Center. Please provide a copy of this Filing Receipt with the changes 
noted thereon. If you received a "Notice to File Missing Parts" for this application, please submit any 
corrections to this Filing Receipt with your reply to the Notice. When the PTO processes the reply to 
the Notice, the PTO will generate another Filing Receipt incorporating the requested corrections (if 
appropriate). 

Applicants) 

Charles R. Cash, New Albany, OH; 
William Douglas Poynter, Duluth, GA; 

Domestic Priority data as claimed by applicant 

THIS APPLN CLAIMS BENEFIT OF 60/151,629 08/31/1999 * 
(*) Data inconsistent with PTO records. / 

Foreign Applications 

If Required, Foreign Filing License Granted 10/17/2000 
Projected Publication Date: N/A 
Non-Publication Request: No 
Early Publication Request: No 



Title 

Lane and front-end effectiveness model 



Preliminary Class 
703 
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LICENSE FOR FOREIGN FILING UNDER 
Title 35, United States Code, Section 184 
Title 37, Code of Federal Regulations, 5.11 & 5.15 

GRANTED 

The applicant has been granted a license under 35 U.S.C. 184, if the phrase "IF REQUIRED, FOREIGN 
FILING LICENSE GRANTED" followed by a date appears on this form. Such licenses are issued in all 
applications where the conditions for issuance of a license have been met, regardless of whether or not a 
license may be required as set forth in 37 CRF 5.15. The scope and limitations of this license are set forth in 
37 CFR 5.15(a) unless an earlier license has been issued under 37 CFR 5.15(b). The license is subject to 
revocation upon written notification. The date indicated is the effective date of the license, unless an earlier 
license of similar scope has been granted under 37 CFR 5. 13 or 5. 14. 

This license is to be retained by the licensee and may be used at any time on or after the effective date thereof 
unless it is revoked. This license is automatically transferred to any related applications(s) filed under 36 CFR 
1.53(d). This license is not retroactive. 

The grant of a license does not in any way lessen the responsibility of a licensee for the security of the subject 
matter as imposed by any Government contract or the provisions of existing laws relating to espionage and the 
national security or the export of technical data. Licensees should apprise themselves of current regulations 
especially with respect to certain countries, of other agencies, particularly the Office of Defense Trade 
Controls, Department of State (with respect to Arms, Munitions and Implements of War (22 CFR 121-128)); the 
Office of Export Administration, Department of Commerce (15 CFR 370.10 (j)); the Office of Foreign Assets 
Control, Department of Treasury (31 CFR Parts 500+) and the Department of Energy . 

NOT GRANTED 

No license under 35 U.S.C. 184 has been granted at this time, if the phrase "IF REQUIRED, FOREIGN FILING 
LICENSE GRANTED" DOES NOT appear on this form. Applicant may still petition for a license under 37 CFR 
5.12, if a license is desired before the expiration of 6 months from the filing date of the application. If 6 months 
has lapsed from the filing date of this application and the licensee has not received any indication of a secrecy 
order under 35 U.S.C. 181, the licensee may foreign file the application pursuant to 37 CFR 5.15(b). 

PLEASE NOTE the following information about the Filing Receipt: 

• The articles such as "a," "an" and "the" are not included as the first words in the title of an application. 
They are considered to be unnecessary to the understanding of the title. 

• The words "new," "improved," "improvements in" or "relating to" are not included as first words in 
the title of an application because a patent application, by nature, is a new idea or improvement. 

• The title may be truncated if it consists of more than 600 characters (letters and spaces combined). 

• The docket number allows a maximum of 25 characters. 

• If your application was submitted under 37 CFR 1.10, your filing date should be the "date in" found on 
the Express Mail label. If there is a discrepancy, you should submit a request for a corrected Filing 
Receipt along with a copy of the Express Mail label showing the "date in. " 

• The title is recorded in sentence case. 

Any corrections that may need to be done to your Filing Receipt should be directed to: 

Assistant Commissioner for Patents 
Office of Initial Patent Examination 
Customer Service Center 
Washington, DC 20231 



